Processors sold by MIPS Technologies™, Sunnyvale, Calif., use and handle addresses differently than traditional Complex Instruction Set Computer (CISC) CPUs. FIG. 1 illustrates a MIPS memory map for a 32-bit processor. The memory map includes a user mode region 102 and kernel mode regions 104, 106 and 108. More specifically, the memory map includes a user space region called “kuseg” 102. The user space region is a 2 GB region spanning virtual addresses 0x0000 0000 through 7FFF FFFF. These addresses are translated by a Memory Management Unit (MMU).
For the kernel mode, there is an unmapped cached region called “kseg0” 104. This region is 512 MB ranging from virtual address 0x8000 000 through 9FFF FFFF. These virtual addresses are translated into physical addresses by merely stripping off the top bit and mapping them contiguously into the lower 512 MB of physical memory. Addresses in this region are almost always accessed through the cache. The addresses are used for most programs and data in systems not using an MMU and are used by the Operating System (OS) kernel for systems that do use an MMU.
The unmapped uncached region is called “kseg1” 106. This region is also 512 MB, with virtual addresses ranging from 0xA000 0000 through BFFF FFFF. These virtual addresses are also mapped into physical addresses by stripping off the leading 3 bits, giving a duplicate mapping of the lower 512 MB of physical memory. In this space, access does not rely upon the cache.
The mapped region is called “kseg2” 108. This 1 GB region spans virtual addresses 0xC000 0000 through FFFF FFFF. This area is only accessible in kernel mode. This region is translated through the MMU.
The Linux operating system is loaded into the kseg0 memory region, which is directly mapped virtual-to-physical memory. Linux loadable modules, primarily installed as device drivers, are loaded into the kseg2 memory region, which is mapped via the MMU. Neither kseg0 nor kseg2 uses Address Space Identifier (ASID) mappings.
In the kuseg region, applications written for the Linux operating system are dynamically loaded. The MMU uses the 8-bit ASID to support up to 256 mapped memory regions (applications) via the TLB hardware system. Each application resides in the same virtual address space (0x0 to 0x7FFFFFFF) and the ASID in a sense extends the address space by 8 additional bits. Beyond 256 different applications (also called processes) the operating system must reuse ASIDs. In particular, Linux does not limit the number of processes to 256. Therefore, it must use a software ID with more than 8 bits. The PID—or process identification (ID)—is used for this purpose. The PID is a 32 bit word.
When the OS sets up an application process and its memory allocation, it assigns it a PID and a mapping to the hardware ASID; these are maintained in a table in OS memory space. When the OS performs a context switch to allow a different process to have CPU time, it sometimes has to remap the ASID assignment to the process. Thus, the PID-to-ASID mapping is not static per process; that is, it is possible for the ASID of a process to change while that process exists. Consequently, virtual addresses alone are not unique in this memory space.
For the purpose of measuring the performance of executing software on a processor using address sampling, it is important to profile the relative time spent executing code at the most detailed sampling level—on per-instruction address granularity for one or more application processes. Since all processes in the user mode space share the same virtual address space, the sampling process must somehow uniquely identify the process that is actively executing so that there are separate sampling bin sets maintained for each process. Again, this issue does not arise in the kernel mode region because there is a direct mapping to physical addresses without regard to the ASID. Therefore, it would be desirable to profile Linux applications in the user mode region where sampled virtual addresses are not unique.